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IP Multicast in RealSystem G2 


Introduction 

This white paper provides a technicai overview of IP muiticast in ReaiSystem G 2 ™. The specific 
protocois, server behavior, server setup, and ReaiSystem™ interoperabiiity with other IP 
multicast enabled applications are discussed in detail. 

ReaiSystem G2 provides two types of multicast: back-channel and scalable. Back-channel 
multicast maintains a RTSP[1] or PNA control channel between the server and the client. The 
data channel is multicasted using RealNetworks’ RDT data packet format and protocol. In 
contrast, scalable multicast uses a data channel only. The data channel is multicasted using 
RTP[2]. There is no control channel between the client and server. 

Back-channel multicast is ideal when the audience is limited in size and quality of service is 
important; however, it does not scale to large audiences due to the amount of system resources 
used for each client connection. This type of multicast includes a data packet resend option that 
is used when multicasted UDP data packets are lost. Back-channel multicast content can be 
authenticated and client connections are logged in the server’s rmaccess.log file. 

Scalable multicast, on the other hand, requires very little server resource whether serving one 
client or one thousand clients. This feature makes scalable multicast ideal for large audience live 
events. Multicast packets are susceptible to typical network packet loss. In scalable multicast, 
there currently is no data recovery mechanism to handle packet loss. 

System Internals 

This section discusses the protocols used, system resource allocation, and implementation of 
each type of ReaiSystem G2 multicast. 

Back-Channel Multicast 

Back-channel multicast maintains a control channel between each client and the server. This 
control channel is implemented using RTSP, or RealNetworks’ PNA. The control channel is used 
to communicate multicast address/port information to the client, content description information 
(e.g., title author, copyright, payload format), client statistics and content authentication. Clients 
request back-channel multicast using either of the following URLs: 

rtsp://server_1/encoder/music.rm 
pnm://server_1/encoder/music, rm 


Back-channel multicast uses RealNetworks’ Real 
Delivery Transport, RDT, as the data packet 
transport protocol. The data is multicasted over 
UDP, which does not guarantee delivery. RDT 
includes a back-channel or resend channel 
between the client and server that is used for 
requesting lost packets. 


If a client cannot connect to a back-channel multicast event, then the client will attempt to connect 
via standard unicast live. This failover feature is useful since a network is not guaranteed to be 
fully multicast-enabled. 

Address use in a multicast system has become a topic of interest since some ISPs are charging 
customers per multicast address used. Back-channel multicast uses one multicast IP address 
and two ports per bitrate for each live session. 
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Back-Channel Multicast and SureStream™ 

Back-channel multicast serves all bitrates defined in a SureStream encoding session or file. The 
server begins multicasting a specific bitrate stream on-demand per client request. The bitrate 
stream that is delivered is determined by the client’s bandwidth setting specified in the client’s 
Preferences dialog box. The client and server use the control channel connection to communicate 
bandwidth information. Only the bitrates that clients request are streamed. 

In other words, back-channel multicast provides a static bandwidth negotiation of SureStream 
data; clients do not dynamically shift bitrates based on changing network bandwidth as it does 
with unicast SureStream streams. 


Scalable Multicast 

RealSystem G2 scalable multicast is a standard 
implementation of multicast. There is no TCP 
control channel between clients and the server. In 
addition, G2 scalable multicast uses many of the 
proposed and draft standard protocols (e.g., RTP, 

RTCP, SDP, SAP) defined by the IETF. This open 
implementation allows RealSystem components 
(e.g., RealServer™ and RealPlayer®) to 
interoperate with other standards based 
applications. See section “Interoperability” for 
more details. 

RealSystem G2 scalable multicast uses RTP/RTCP as the data packet transport and session 
reporting protocol. The RTP specification requires two ports to be allocated. One port is used for 
data transmission and the other port is used to report on quality of data delivery. The first port 
must be an even number (e.g., 8000) and the second port must follow the first port number (i.e., 
8001). The data is delivered over UDP. 

The client accesses RealSystem G2 scalable multicast by loading a SDP[3], Session Description 
Protocol [3] file. Each live session is described using SDP. The SDP file contains the multicast 
address/port, and other session description information (e.g., title, author, copyright, payload 
type). The server creates an SDP file on the fly by client request. The SDP file can be saved to 
disk and later loaded into the client. Clients request scalable multicast content using the following 
URL: 



http://server_1 :http_port/scalable/live.rm.sdp 

The server periodically multicasts the session information using the SAP, Session Announcement 
Protocol [4]. SAP is used by standard multicast applications to announce multicast sessions. The 
SAP specification defines a known multicast address/port. Servers multicast session information 
using the SDP format to this known address/port. Session listener applications (e.g., sdr, ICAST 
Viewer) that function as multicast TV Guides pick up the SAP multicast and provide a digest of 
current or planned multicast sessions. 

Currently, RealSystem G2 scalable multicast does not automatically shift to unicast delivery if 
multicast delivery fails. However, you can provide both the multicast and the unicast URL links in 
a Web page. Failover to unicast will be added to RealSystem G2 scalable multicast in the next 
release of RealSystem G2. 


RealNetworks, Inc. 


Page 3 of 14 





IP Multicast in RealSystem G2 


Client connection statistics are not available when using RealSystem G2 scalable multicast. 
There is no way to determine how many clients are currently tuned into the session and for how 
long. However, the server access log file does list all users who retrieved the SDP file. This 
feature will be added to RealSystem G2 scalable multicast in the next release. 

Scalable multicast uses a unique multicast address for each multicasted stream. For instance, 
video content requires two multicast streams: one for the audio stream and one for the video 
stream. Each stream requires two ports per the RTP specification. A future release of 
RealSystem G2 scalable multicast will allow the server administrator to “force” the server to use 
one multicast address for both streams in a video feed. 

Note that you cannot run the RealServer and RealPlayer in scalable multicast at the same time 
on the same system because both applications reference the same multicast address and port. 

Scalable Multicast and SureStream 

Scalable multicast supports SureStream by multicasting each stream on a unique multicast 
address/port. Each stream is described in the SDP file that is provided to the client. The client 
chooses the stream to tune in to based on its bandwidth preference setting. The client does not 
dynamically up/down shift to different streams to adjust to changing network conditions as it does 
with unicast SureStream data. 

Scalable multicast will serve each bit rate in a live SureStream encoding session. Keep in mind 
that the more SureStream bitrates you choose to encode, the more bandwidth you will be using. 
Why? Because with scalable multicast, each stream is sent over the wire. So use SureStream 
with scalable multicast judiciously. Select bitrates that will cover the majority of your target 
audiences. A future release of scalable multicast will provide the server administrator greater 
control over which SureStream bitrates to multicast. 


Multicast and Splitting 

RealSystem G2 supports a scalability feature called splitting. In splitting, one or more RealServer 
servers join the main RealServer to distribute streams. These splitter servers serve content and 
therefore multiplying the number of streams served. As you can see, this feature provides a 
mechanism to do large scale 
broadcasting. Please review 
the RealSystem G2 
Administration Guide, section 
8 “Splitting and Multicasting” 
for details on splitting. Below is 
a bird’s eye view of how 
splitting works. 


The current version of 
RealSystem G2 splitting 
supports multicasting only at 
the end servers; the servers 
that connect to RealPlayers. 
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Setting Up a Live Session 

There are three steps to setting up and verifying a iive muiticast session. The foiiowing sections 

eiaborate on these three steps. 

1 . Configure RealServer. The first step is to configure the server for muiticast (e.g., back- 
channei and/or scaiabie). You can configure the server to deiiver unicast, back-channei and 
scaiabie muiticast simuitaneousiy, as weii. 

2. Setup a “live” data source. This couid be a genuine iive feed (audio and/or video) or a 
simuiated iive feed using the g2sita with an existing ReaiMedia fiie. 

3. Provide URL access to the live session. Typicaiiy, you wiii want to create a Web page that 
contains the iinks to the iive sessions. The URL format for accessing back-channei and 
scaiabie muiticast are different. The URL format for accessing back-channei and unicast iive 
content is the same. 

Configuring Back-Channei Muiticast 

In this section, step-by-step instructions of how to configure back-channei muiticast is provided. 

Back-channei muiticast can be accessed using the PNA or RTSP protocois for the controi 

channei. For this reason you must specify the ports that the server wiii iisten on for PNA and 

RTSP requests from ciients. 

1 . PNA Port: The port that the server iistens for ciient connections. 

2. RTSP Port: The port that the server iistens for ciient connections. 



3. Address Range: This must be set to a range of vaiid IP multicast addresses that you want 
the server to use to multicast the media data. This configuration variable is specified as a 
range rather than a single address because you may want to multicast more than one live 
session at the same time. For instance, if you plan to broadcast three live sessions, then you 
will need 3 addresses in the Address Range. Back-channel multicast streams the audio and 
video streams together. Scalable multicast uses a unique address/port combination for the 
audio and video streams. 
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4. Time to Live (TTL): This setting controis the distance that muiticast packets can travei over 
a network. A router wiii decrease the TTL vaiue by 1. When the vaiue reaches 0, the packet 
is discarded and is not forwarded. The vaiid range for TTL vaiue is 0 to 255. A TTL of 0 
means that the packet does not ieave the host system. The greater the vaiue of the TTL, the 
greater the distance the packet wiii travei over a network. 

5. Resend: The ciient can request from the server a resend of data packets that have not 
arrived. Since muiticast packets are sent over UDP, there is a possibiiity that packets sent by 
the server wiii not reach the ciient. Set this vaiue to “Yes” if you want the ciient to request 
missing packets. This feature improves the quaiity of a presentation. Missing data packets in 
an audio or video presentation can degrade the quality of the user experience. 

6. Delivery Only: This setting applies to the User List configuration variable. If set to Yes, the 
server will send multicast streams to the clients specified in the User List; there is no failover 
to unicast for the set of clients listed in the User List. This configuration variable can be used 
to help control bandwidth to a set of users. Set this variable to “No” if you want all clients to 
receive multicast. 

7. User List: This configuration 
variable is used to specify a range 
of clients that you want to receive 
multicast data only. To add a 
user, click on “Add a User List”. 


■ In the dialog box, enter a 
“Rule Name”; this must be a 
number (e.g., 100, 200). 


- In the “IP Address” text box, 
add the domain address of 
the client computer or 
network (e.g., 121.23.101.0). 


- In the “Netmask” text box, 
add the mask that specifies 
what bits in the domain 
address that are wildcards 
(e.g., 255.255.255.0). For 
example, if the IP address is set to 121.23.101.0 and the netmask is set to 
255.255.255.0, then the server will send multicast packets to clients with IP addresses 
from 121.23.101.0 to 121.23.101.255. The “Rule Name” is used for tagging different sets 
of user lists. 

■ Click on “Add” to save your changes. 
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8. Finish: Click on the “Apply” button to save configuration changes made for back-channel 
multicast. You must restart the server in order for these changes to be enabled. 


User List 


Rules: 


Address: | 



Netmask: | 



ADD A USER LIST 

REMOVE A USER LIST 


Configuring Scaiabie Muiticast 

In this section, step-by-step instructions of how to configure scalable multicast is provided. 

1 . Host Address: Enter the IP address of the host computer that the RealServer is running on. If 
this variable is given a value, the server will multicast all live session descriptions using the 
“Session Annoucement Protocol”, SAP [4]. If this variable is blank, the server does not multicast 
live session information over SAP. SAP “listener” applications, such as, SDR and ICAST Guide, 
will display the sessions being multicasted by the RealServer. This variable is optional. 

2. Mount Point: Enter a string that is used in the URL to access scalable multicast sessions. 

The default value is “/scalable/”. This variable is required. 


Scalable 



Host Address: 1 



Mount Point: | 




In scalable multicast, you can set up each live session or source to have its own set of 
configuration settings. This provides the user with greater control over each live session. To add 
a live source, click on “Add a Live Source”. A dialog box is displayed. 

1. Enabled: Set this value to “True” if you want the server to multicast this live source or 
session. You can set this to “True” or “False” at run time to turn multicasting on or off. 
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2. Virtual Path: This variable allows 
you to tune the live source to a 
specific set of live content. Set this 
value to a string that you used in 
the encoding tool (e.g., 

RealProducer or g2slta). For 
instance, in the RealProducer you 
are prompted to specify a “Path 
Name” for the live encoding. You 
can specify “live.rm” or you can 
specify “classical_music/live.rm”. 

The virtual path in the former 
example is and in the latter 
example is “classical_music”. This 
is useful if you are encoding more 
than one type of classical music 
and you want all live classical 
music sessions to share the same 
scalable multicast configuration 
settings. The “Virtual Path” is used 
in the URL the client uses to 
request scalable multicast content. 

For instance, the URLs for the two 
examples given above are: 

http://server_1 :http_port/scalable/live.rm.sdp 
and 

http://server_1 :http_port/scalable/classical_music/live.rm.sdp 

3. Port Range: For each IP multicast address used, you must provide at least two ports, where 
the first port is an even number. Scalable multicast uses RTP as the data packet transport 
protocol. This protocol requires two ports per stream. 

4. Address Range: This must be set to a range of valid IP multicast addresses. Each stream in 
the presentation uses a different IP address from this range. Note that a video presentation 
contains an audio and video stream. For example, if you plan to broadcast two video 
sessions, then you will need a minimum of four addresses. If you plan to broadcast three live 
audio sessions, then you will need a minimum of three addresses in the Address Range. 

5. Time to Live (TTL): This setting controls the distance that multicast packets can travel over a 
network. A router will decrease the TTL value by 1. When the value reaches 0, the packet is 
discarded and is not forwarded. The valid range for TTL value is 0 to 255. A TTL of 0 means 
that the packet does not leave the host system. The greater the value of the TTL, the greater 
the distance the packet will travel over a network. 

6. Finish: Click on the “Add” button to save your entries. Click on the “Apply” button to save the 
entries for this page. You must restart the server in order for these changes to be enabled. 

Setup A Live Data Source 

Now you are ready to set up an encoding session using the RealProducer or the g2slta. The 

following sections contain instructions on starting a simple encoding session using the 

RealProducer and the g2slta. 
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Using the RealProducer 

In this example, you will encode audio from your CD-ROM. Start the RealProducer. Insert a 

musical CD in your CD-ROM drive. 

1. Configure the RealProducer for capturing audio. 

2. Add media clip information. 

3. Select SureStream or single bitrate encoding. 

4. Select the target audiences by choosing the bitrates. 

5. Configure the RealProducer to broadcast the encoding session. Choose the File menu, “New 
Session...” menu item. 

6. Click on “Media Device” to encode from the CD-ROM drive. Check the “Capture Audio” box. 

7. Click on “Live Broadcast” as the output type. 

8. For “RealServer”, enter the hostname or IP address of the system where the RealServer is 
installed. 

9. For “Server Port”, enter the encoder port that the server listens on for encoder connections. 
This port is set during RealServer installation. The default is”4040”. If you do not remember 
this port number, you can look it up using the RealAdministrator. 

10. For “Filename”, enter simply “live.rm” or “my_fave_tunes/live.rm”. The information you enter 
in this text box must match the “Virtual Path” server configuration variable. For “live.rm”, the 
“Virtual Path” value should be For “my_fave_tunes/live.rm”, the “Virtual Path” value 
should be “my_fave_tunes”. 

11. For “Username” and “Password”, enter the values you used when you installed the 
RealServer. (How can you look this up if user forgot?) 

12. Click on the “OK” button. 

13. Finally, click on the “Start” button. 

Check the server error log file for messages. Scalable multicast will log a message if the 

multicast was started successfully. You will see a message like this: 


01-Jan-99 17:58:38.116 logplin(30454): Scalable Multicast: Successfully start session: “live.rm” 

Back-channel multicast does not report successful configuration. The only way to verify that this 
is working is to load the back-channel URL in a client. See section “URL Access to a Live 
Session” for the details on accessing multicast content. 
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Simulate Live Broadcasts (g2slta) 

RealSystem G2 provides a mechanism that permits you to re-broadcast an archived live event. 
RealSystem G2 provides a utility called g2slta (“simulated live transport agent”) that allows you to 
simulate a live session with any RealMedia (.rm) file. This utility can be found in the RealServer 
Bin directory. This section provides step-by-step instructions on running the g2slta. Please refer 
to your RealServer Administration Guide, “Simulating a Live Broadcast” section for more details 
on using g2slta. 



Workstation 


RealProducer 
or g2slta 



IBM Compatible Workstation 


RealServer 


RealPlayers 


Instructions on how to use g2slta are printed to the terminal window. On Window’s based 
systems, the g2slta is wrapped in a batch file, g2slta.bat; on Unix systems, the g2slta is wrapped 
in a shell script file, g2slta.sh. These script files set the environment variables that are used by 
the g2slta executable. Type the command for g2slta to get a display of the command line 
arguments. 

E:\RealG2\RealServer\Bin>g2sita.bat 

E:\RealG2\RealServer\Bin>REM G2SLTA Helper Batch Script 

E:\RealG2\RealServer\Bin>REM version 1.0 1998/11/12 - lesterj 

E:\RealG2\RealServer\Bin>echo off 

G2SLTA.EXE - Live Broadcast Simulation Utility 

Copyright 1998, RealNetworks, Inc. All Rights Reserved 

Usage: 

host port userid password livefile playlist file [-r] [-nN] [-bN] 

-r: random. 

-nN: play N files, then exit. 

-bN: target stream bandwidth of n Bps 

Playlist file has the format: 

filel 

file! 

G2SLTA requires that two environment variables, G2SLTA_PLUGIN_PATH and 
G2SLTA_SUPPORT_PATH, be set. These variables reference the Plugins and 
the LibrarySupportPath variables specified in your G2 echo RealServer's 
configuration file ( i.e. rmserver.cfg ). If you change these values in 
your server configuration file, you must make modifications to lines 16 
and 17 of this script file. 

Refer to the G2 RealServer documentation for more informatin regarding the 
G2SLTA utility. 
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The following section provides step-by-step instructions on how to use the g2slta. 

1. Start the RealServer. This must be running before we start g2slta. 

2. In a terminal or command window, change directory to the RealServer Bin directory. 

3. Create a playlist file. This is a ASCII text file that contains the title, author, copyright, and 
location of the RealMedia file that you want to stream. The title, author, and copyright lines 
are optional. The current version of the g2slta can stream only a single bit-rate. For 
convenience, provide a single bit-rate encoded RealMedia file. Create a text file, mytest.pis, 
in this directory, using your favorite editor (e.g., notepad, vi). Add these lines to the file: 

Title: This is a test 
Author: Me 
Copyright: None 

e:\realg2\realserver\bin\single_bit_rate.rm 

4. Start the g2slta. Run the command given below but substitute the command arguments with 
the values that are appropriate for your system. Specifically, replace “darlene” with the name 
of the host machine where the RealServer is running; replace “4040” with your G2 encoder 
port. If you don’t remember what port you specified during installation, then you can use the 
RealAdministrator to find it. Choose “Broadcasting” and click on “G2 Encoder”. The port is 
listed on this page. Replace “foo” and “foo” with the login and password that you chose when 
installing the RealServer. This login and password is used to get into the RealAdministrator 
and the G2 Encoder. Use “mylive.rm” and “mytest.pis”. The latter is the name of the playlist 
file that you created in your text editor that you created in step 3. 

E:\RealG2\RealServer\Bin>g2slta.bat darlene 4040 foo foo mylive.rm mytest.pis 

E:\RealG2\RealServer\Bin>REM G2SLTA Helper Batch Script 

E:\RealG2\RealServer\Bin>REM version 1.0 1998/11/12 

E:\RealG2\RealServer\Bin>echo off 

G2SLTA.EXE - Live Broadcast Simulation Utility 

Copyright 1998, RealNetworks, Inc. All Rights Reserved 


Executing G2SLTA with 

host=darlene, port=4040, userid=d, password=d, livefile=mylive.rm, playlist 
file=mytest.pis. 

Encoding e:\realg2\realserver\content\jewel.rm... 

5. Check for errors. Check the server log file, rmerror.log, for any error messages. 

6. Play the simulated stream. Start the RealPlayer and type the following URL into the “Open 
Location” dialog box. Note that the file name referenced, mylive.rm, is the name you specified 
in the g2slta command. Also, note that the title, author, and copyright information given in the 
playlist file is what the player displays. 

rtsp://darlene/encoder/mylive.rm 

Limitations 

The current version (1.0) of g2slta does not stream SureStream encoded files. The g2slta can 
select a single bit rate from a SureStream file and broadcast this one stream, using the -bN 
argument. N is the target bitrate that you want g2slta to select from the multi-bitrate SureStream 
encoded file. For instance, if you want g2slta to select a 20kbps bitrate stream from a SureStream 
encoded file, add the -b20000 to the g2slta.bat command above. To see all the valid command 
line arguments for g2slta, just type “g2slta.bat” (for Windows) or “g2slta.sh” (for Unix) at the 
terminal window prompt. 
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URL Access to a Live Session 

Your client must be configured to receive multicast content. The default behavior of the client is to 
receive live content using multicast. However, you may want to check to see if your client’s 
transport settings are set to receive multicast. To configure the client to receive multicast for live 
content, open the client’s preferences dialog box and click on the “Transports” tab. Click on the 
“RTSP” and the “PNA” buttons. Check the appropriate check boxes to receive multicast. 

To access the back-channel multicast or unicast of a live session, enter this URL into the client’s 
“Open Location” dialog: 

pnm://server_1/encoder/live, rm 
rtsp://server_1/encoder/live.rm 
rtsp://server_1/encoder/my_fave_tunes/live.rm 

“server_1” is the name of the system where the RealServer is installed, “encoder” is the name of 
the “Mount Point” used for G2 encoders. The default value is “encoder”. The file that is 
referenced is the pathname of the content you specified in the RealProducer or the g2slta. 

If the client is configured for multicast and the network is multicast enabled, then the content will 
be delivered using multicast; otherwise, unicast delivery will be used. To verify the transport type 
used, open the client’s statistics dialog box and click on the “Streams” tab. There is a “Transport” 
label with either “UDP” or “TCP” or “multicast” or “PNAviaHTTP” or RTSPviaHTTP” as the value 
depending on the transport used. 

To access scalable multicast of a live session, enter an URL of the following format in the client’s 
“Open Location” dialog: 

http://server_1 :http_port/scalable/live.rm.sdp 
http://server_1 :http_port/scalable/my_fave_tunes/live.rm.sdp 
http://server_1 :http_port/scalable/space.au.sdp 

“server_1” is the name of the system where the RealServer is installed, “scalable” is the name of 
the “Mount Point” that you used when configuring the server. The default is “scalable”. The file 
that is referenced is the pathname of the content you specified in the RealProducer or the g2slta, 
with the extension “.sdp” added on the end. The “.sdp” extension causes the client to download 
the client-side scalable multicast plugin using the client’s auto-update feature. 

Since scalable multicast does not failover to unicast mode, you may consider providing the URL 
for the unicast stream. Note: this URL can be one of the ones listed for back-channel multicast or 
unicast given above. 

The SDP file can be downloaded and saved as a local file. To do this, you can enter the URL 
shown above into your web browser. The browser prompts you to download the file to disk. This 
SDP file can be loaded into the client using the file open dialog or simply dragged and dropped 
onto the client. The SDP file can also be supplied as a link in an HTML page. 

This is an advantage to using the indirect method for retrieving the SDP file; all clients do not 
need to make any connection to the server to retrieve the SDP file. The client loads the SDP file 
that contains the multicast address/port information to connect to the live multicast session. 
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Scalable Multicast and Interoperability 

Scalable multicast Is Implemented using standard protocols such as RTP, SDP, and SAP. For 
this reason, RealSystem G2 can Interoperate with other applications that use these standard 
protocols. This section discusses some third party applications that work with RealSystem G2. 

Using ICAST to View ReaiSystem G2 Muiticast Sessions 


The ICAST guide Is multicast TV guide 
application. It listens for SAP messages 
and displays the SDP Information 
contained within. Below Is a snapshot of 
the ICAST Guide showing a RealServer 
multicast session. 

In this example, the RealServer Is 
multicasting an AU file using the g2slta. 

You may not see live sessions of Real 
data types In the ICAST Guide because 
the SDP file Is compressed. For non- 
Real data types (e.g, AU, WAV, H261) 
the SDP file Is not compressed. The 
SAP specification states that the SDP 
payload should not exceed 1 KB. 

Packets of size greater than 1 KB risk 
being fragmented over the network. We 
have found that ICAST Guide does not 
pick up these compressed SDP 
messages. 

It would be Ideal If we could launch the 
player from the ICAST guide. You can 
associate the RealPlayer with the data 
type In ICAST Guide but these Is no 
seamless way to transfer the SDP file to the player from the ICAST Guide that we have found. 
Right now we load the SDP file from the ICAST Guide temp directory. The files end In .sdp. Do a 
search and you will find where your temp directory Is located. 

Below Is a sample SDP file for the Spacemusic entry shown above In the ICAST Guide. SDP files 
can be loaded Into the player directly. Type the scalable multicast URL Into your browser to 
retrieve the SDP file of a current scalable multicast session. You may need to change the 
browser mimetype for .sdp files to save the file to disk. 
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IP Multicast in RealSystem G2 


V=0 

0=- IN IP4 
s= Spacemusic 

i= RealSystem G2 scalable multicast and SAP. Nice space music for the end of the millenium. 

a=LiveStream:integer;1 

a=StreamCount:integer;1 

a=Title:buffer;"IFNwYWNIbXVzaWMA" 

a=Copyright:buffer;"IE5pY2Ugc3BhY2UgbXVzaWMgZm9ylHRoZSBIbmQgb2YgdGhllG1pbGxlb 

ml1bS4A" 

a=Author:buffer;"IFJIYWxTeXN0ZW0gRzlgc2NhbGFibGUgbXVsdGljYXN0IGFuZCBTQVAulAA=" 
t=0 0 

m=audio 9102 RTP/AVP 0 
a=control :streamid=0 
a=rtpmap:0 x-pn-au 
a=length :npt=6.003000 
a=mimetype:string;"audio/x-pn-au" 

C=IN IP4 234.1.1.31/9 

a=AvgBitRate:integer;64000 

a=StartTime:integer;0 

a=RMATimestampConversionFactor:integer;1 

a=AvgPacketSize:integer;320 

a=RTPTimestampConversionFactor:integer;8 

a=LiveStream:integer;1 

a=Preroll:integer;0 

a=MaxPacketSize:integer;320 

a=MaxBitRate:integer;64000 

a=OpaqueData:buffer;"AQABAEAfAAA=" 

a=StreamName:string;"audio/x-pn-au" 
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